Skip to content

Fix --incremental crash on Type[...]#4038

Merged
JukkaL merged 2 commits intopython:masterfrom
ilevkivskyi:fix-type-incremental
Oct 11, 2017
Merged

Fix --incremental crash on Type[...]#4038
JukkaL merged 2 commits intopython:masterfrom
ilevkivskyi:fix-type-incremental

Conversation

@ilevkivskyi
Copy link
Member

@ilevkivskyi ilevkivskyi commented Sep 30, 2017 •
edited by gvanrossum
Loading

This fixes the second traceback reported in #3852. This also improves member lookup on Type[...] by moving it to a later stage (checkmember.py instead of some manipulations in TypeType constructor that are dangerous during de-serialization).

By the way it looks like the first traceback reported in #3852 is just another manifestation of #3052, but instead of just deleting a class it is replaced by a Var or by a FunctionDef.

Also fixes #4058.

@gvanrossum
Copy link
Member

gvanrossum commented Sep 30, 2017

Is this something urgent (fixing a regression in a recent change) that should be cherry-picked into the release branch? Or is this something that has been around for a long time? It seems the second crash in #3852 is related to pointing mypypath to site-packages, which is not recommended.

@ilevkivskyi
Copy link
Member Author

ilevkivskyi commented Oct 2, 2017

Is this something urgent (fixing a regression in a recent change) that should be cherry-picked into the release branch? Or is this something that has been around for a long time?

The bug is quite old (around a year), it started to be a crash in 0.510. So I don't think it is something urgent.

It seems the second crash in #3852 is related to pointing mypypath to site-packages, which is not recommended.

The crash doesn't depend on MYPYPATH setting, but the probability to find more dynamic code in libraries is higher. For example, the crash appears on type(f) , where f is a callable other than class object.

This was referenced Oct 2, 2017
Closed
Closed
@ilevkivskyi ilevkivskyi mentioned this pull request Oct 9, 2017
Closed
@JukkaL JukkaL self-assigned this Oct 9, 2017
JukkaL
JukkaL reviewed Oct 10, 2017
View reviewed changes
mypy/types.py
self.item = item.fallback
else:
self.item = item
self.item = item
Copy link
Collaborator

@JukkaL JukkaL Oct 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this change help? Is it because the type attribute of an Instance might refer to FakeInfo during deserialization?

Copy link
Member Author

@ilevkivskyi ilevkivskyi Oct 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Member Author

@ilevkivskyi ilevkivskyi Oct 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Or previously to None)

JukkaL
JukkaL approved these changes Oct 11, 2017
View reviewed changes
Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the fix!

@JukkaL JukkaL merged commit bd1b3d7 into python:master Oct 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JukkaL JukkaL JukkaL approved these changes

Assignees

@JukkaL JukkaL

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

self.__class__.__name__ has type Any in class derived from Any

3 participants

@ilevkivskyi @gvanrossum @JukkaL